Actionable comments posted: 2

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/prisma-next/src/v3/codec-runtime-v3.ts`:
- Around line 291-312: Update decodeJson in
packages/prisma-next/src/v3/codec-runtime-v3.ts to return null immediately when
the JSON value is null, matching decode’s nullable-column behavior before
routingKeyFromPayload runs. Add coverage in
packages/prisma-next/test/v3/codec-runtime-v3.test.ts at lines 351-361 verifying
decodeJson(null) round-trips as null; no other sites require changes.

In `@packages/prisma-next/test/psl-interpretation.test.ts`:
- Around line 17-20: Move packages/prisma-next/test/psl-interpretation.test.ts
into the appropriate __tests__/ directory and update its relative imports and
test configuration. Move
packages/prisma-next/test/v3/vendored-space-parity.test.ts under __tests__/ as
well, adjusting all relative paths for the new location while preserving both
suites’ behavior.

Actionable comments posted: 1

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/prisma-next/test/descriptor.test.ts`:
- Around line 120-129: The descriptor test’s loose substring and size checks do
not verify the exact migration bundle. Update the assertions around installOp
and its execute SQL to reuse the frozen SHA-256/digest verification established
by migration-v3.test.ts, comparing the embedded SQL against the expected release
provenance without calling readInstallSql() or reading the installed package at
runtime.

Reviewed by Claude Code on behalf of James Sadler.

Verdict: Approve

I reviewed all three bundled concerns with a focus on the digest verification, payload-identifier routing, and the dependency upgrade. The security-sensitive code is correct and well-tested. No blocking issues.

Digest verification (eql-bundle-v3.ts) — correct

• assertInstallSqlDigest computes sha256 over the install SQL and compares against releaseManifest.installSqlSha256, throwing on mismatch (fails closed). Right algorithm, right bytes, right direction.
• readVerifiedInstallSql() is the sole sanctioned emit source, so an ops.json can never be baked from bytes the pinned release does not attest to. Consistency of the digest computation is proven by assertInstallSqlDigest(readInstallSql()) passing in CI.
• Apply-time integrity correctly hands off to the framework's existing verifyMigrationHash over the on-disk bytes (the baked SQL is inside ops.json, so tampering changes the migrationHash). The e2e tamper test (injected DROP TABLE rejected before execution) confirms the trust chain end-to-end.
• The provenance test suite is well-designed: per-migration FROZEN literals (migrationHash + installSqlSha256) tied to each migration's OWN release, a completeness check against the on-disk directory set, and a single bump-safe LOCKSTEP check (.toContain(releaseManifest.installSqlSha256)). An EQL bump without a matching re-emit fails, while historical migrations keep their frozen digests. The committed migration.json hashes (2c873907…, 7bb96043…) match the frozen literals.

Payload-identifier routing (codec-runtime-v3.ts) — cryptographically sound

• Reading (t, c) from the payload's own i identifier is authoritative because ZeroKMS commits the cell key to that identifier: a relocated/tampered payload fails to decrypt (fails closed). Trusting i is therefore no weaker than trusting the query AST, and it unblocks aggregates, computed projections, and decodeJson (relation includes).
• No cross-tenant risk: the codec instance closes over a fixed this.#sdk (which carries tenant/dataset credentials). The payload only influences (table, column), never the SDK, so a payload cannot redirect decryption to another tenant.
• routingKeyFromPayload correctly rejects non-object/null/empty-string cases. decode keeps ctx.column as a fallback only when no identifier is present; decodeJson fails closed with a diagnostic. Good test coverage including the prefer-payload-over-ctx case and the non-round-trippable encodeJson marker.

Prisma Next 0.16 upgrade — coherent

• 31 @prisma-next/* pins bumped in lockstep; pnpm-lock.yaml shows only registry (npmjs integrity) resolutions — no git/tarball sources.
• createNamespace: postgresCreateNamespace added to both configs (0.15 requirement) and the PSL interpreter test migrated to the CST parse + buildSymbolTable input, consistent with the changeset notes.

Non-blocking observations

1. Baseline bytes changed (one-time invariant exception). This PR changes the baseline migration's ops.json/hash (35fc9000… → 2c873907…) while simultaneously establishing the "published migrations are immutable by dirName, never re-emit" invariant. That is a legitimate transition commit (moving off the sentinel/runtime-injection scheme) and the PR body documents the rc-consumer reset, but it is worth being explicit that this is a deliberate one-time exception to the very invariant being introduced — after this lands, the append-only rule must hold strictly.
2. decode now silently prefers the payload identifier even when it disagrees with ctx.column. Intentional and safe (key commitment makes it the correct identity), but it removes the implicit cross-check that previously surfaced misplaced-data bugs as decryption failures. A value that ends up in the wrong column now decodes silently by its true identity. Not a security issue, but a low-cost diagnostic (warn when routingKeyFromPayload and ctx.column disagree) would preserve that signal. Optional.
3. Both migrations bake identical 3.0.2 SQL (same installSqlSha256); baseline+upgrade both land on the 3.0.2 surface for a fresh DB, relying on the install bundle's re-install idempotency. Fine and documented, just noting it is load-bearing on that idempotency claim.